System and Method for Normalizing and Communicating Care Plans

ABSTRACT

A system and method for normalizing and communicating health care plans is provided. In one aspect of the invention, the method includes converting one or more care plans into a common digital format, identifying tasks within the care plans, determining if one or more of the tasks are in a standardized form, and classifying the tasks if the tasks are in a standardized form. In another aspect of the invention, the method includes unifying the one or more care plans, selecting one or more communication mediums for communicating care plans, and communicating the care plans to one or more users and or patients.

BACKGROUND OF THE DISCLOSURE

In general, treatment of patients having comorbidity costs thehealthcare system much more than it costs to treat patients withoutcomorbidity. Moreover, many comorbid patients still struggle toeffectively treat their health.

Comorbid patients are those diagnosed with one or more illnesses thatare co-occurring. One reason that may result in the failure of comorbidpatients to effectively treat their health is poor compliance oradherence when executing health care plan instructions. Moreover,because comorbid patients often see more than one physician, comorbidpatients often receive fragmented health care coordination. Also, due toconfusing or potentially hazardous care plan instructions, many comorbidpatients cease to follow care plans directives. This can worsen theproblem and add to the increased cost of health care.

Care plans are typically used to provide information and instruction topatients for the management and recovery of their health. These careplans are used by professional health care providers such as hospitalsand clinics, but may also be used by professional health care providersin assisted living situations and home care. Moreover, care plans maycome in many different forms and may be used for many differentpurposes.

A discharge folder is one example of a paper-based care plan that cancontain patient discharge instructions and other useful information thatpatients may review at home after being discharged from a hospital.Discharge folders may also include a list of tasks a patient needs toperform so that the patient can experience a better recovery. Forexample, a discharge folder may contain a list of instructions directingpatients to take a certain medication a number of times each week. Asanother example, a discharge folder may contain instructions directingpatients to perform certain exercises periodically, or containeducational information related to the illness.

Although, the typical care plan provides information and instructionnecessary for the successful recovery of a patient, many care plansutilized by health care providers are not normalized across systems andare often altered and communicated to patients in writing using shorthand notation or other means.

Further, though some providers of care plans communicate health careinformation using electronic means such as computers, because of thelack of care plan normalization, many care plans cannot be altered inreal time, merged, or effectively communicated and understood betweendifferent systems. This is especially true with multiple distributedcare plans that have not been compared and normalized for consistency toaddress a patient's unique needs.

It is therefore desirable to have a system and method for normalizingmultiple care plans. It is also desirable to have a system and methodthat supports multidirectional modification and communication ofnormalized care plans. The subject matter of the present disclosure isdirected to addressing one or more of the problems set forth above.

SUMMARY OF THE DISCLOSURE

A system and method for normalizing and communicating health care plansis provided. In one aspect of the invention, the method includesdigitizing, unifying, and communicating one or more health care plans.In one example, the method includes digitizing care plans by convertingthe care plans into a common digital format, identifying tasks withinthe one or more care plans, and classifying the tasks if the tasks arein a standardized form. According to another aspect, the methodstandardizes tasks within the one or more care plans by formatting thetasks, receiving input for selecting options related to a user's health,and associating content with the tasks.

In still another aspect of the invention, the method unifies one or morecare plans into a unified care plan and communicates the unified careplan to users. In this aspect, the method includes using internal and orexternal resources for identifying potentially hazardous care plancontent. In another aspect of the invention, the method includesselecting one or more communication mediums for communicating unifiedcare plans. In yet another aspect of the invention, the method allowspersonalizing a unified care plan by allowing the care plan content suchas color, font, contrast, sound, orientation, metadata, and or style tobe modified. In another aspect of the invention the method allowspersonalizing of care plan content through the use of a GUI interface.

According to another aspect, the method allows formatting care plantasks by formatting one or more quantitative expressions and languagecontent using location information. A different aspect of the inventionalso allows communicating associated content information with the careplan communication.

The foregoing summary is not intended to summarize each potentialembodiment or every aspect of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system diagram of a healthcare management system(HMS) according to the present disclosure.

FIG. 2 illustrates a system diagram of a digitization module of the HMSaccording to the present disclosure.

FIG. 3 illustrates a system diagram of a unification system of the HMSaccording to the present disclosure.

FIG. 4 illustrates an example HMS process according to the presentdisclosure.

FIG. 5 illustrates an example digitization process according to thepresent disclosure.

FIG. 6 illustrates an example standardization process according to thepresent disclosure.

FIG. 7 illustrates a block diagram of the HMS of FIG. 1 according to thepresent disclosure.

FIGS. 7A-7D are block diagrams of the hardware, software and data of thecomputers of FIG. 7.

FIG. 8 illustrates example health care plans according to the presentdisclosure.

FIG. 9 illustrates a flow diagram of a digitization process according tothe present disclosure.

FIG. 10 illustrates a flow diagram of a unification process according tothe present disclosure.

FIG. 11 illustrates a flow diagram of a communication process accordingto the present disclosure.

FIG. 12 illustrates one example of a unified care plan accessed througha web portal using a client device according to the present disclosure.

FIG. 13 illustrates an additional example of a unified care planaccessed through a web portal using a client device according to thepresent disclosure.

FIGS. 14A-14B illustrate additional examples of health care plansaccording to the present disclosure.

FIG. 15 illustrates an additional example of a unified care planaccessed through a web portal using a client device according to thepresent disclosure.

FIG. 16 illustrates an additional example of a unified care planaccessed through a web portal using a client device according to thepresent disclosure.

FIG. 17 illustrates an example prompt generated by the system requestinginput from a user.

DETAILED DESCRIPTION OF THE DISCLOSURE

Overview of the System

A brief overview of the architectural components and their relationshipsbetween each other will now be described.

FIG. 1 illustrates a system diagram of a HMS 100 used for normalizingand communicating care plans according to the present disclosure. Asshown, the HMS 100 includes a digitization module 110 for digitizing oneor more health care plans. Also as shown, the HMS 100 may be implementedon one or more host servers or other device 105 having memory, one ormore processors, and at least one wired or wireless communicationinterface 140 for establishing communications with one or more clientdevices 145.

The system 100 also includes a unification module 115 for unifyinghealthcare plans into a single unified plan. Also as shown, acommunication module 120 is communicatively coupled to the digitizationmodule 110 and unification module 115. As discussed below, thecommunication module 120 is used to communicate care plan content withone or more client devices 145.

The communication module 120, is used to assist users (e.g., physicians,healthcare professionals, family, etc.), and patients in selecting oneor more communication mediums such as email, text messaging, etc, to beused during care plan communication.

Also, as shown, the communication module 120 is communicativelyconnected with one or more client devices 145 such as cellular phones,personal digital assistants (PDAs), computers, or other digital devices.By communicating with one or more client devices 145, the communicationsmodule may allow a users and patients to access care plan informationthrough a web portal using graphical user interface (GUI).

Further as illustrated, and also communicatively coupled to thecommunication module 120, is a database 135 that stores informationrelated to a patient's healthcare including one or more healthcareplans, medical records, and or other related information. In oneexample, the database 135 is communicatively coupled to the digitizationmodule 110 and or unification module 115.

Referring to FIG. 2, a system diagram of a digitization module 110 ofthe HMS 100 is shown. As described below, the digitization module 110includes a conversion module 205 which is used to convert one or morehealthcare plans into a digital format. The digitization module 110 alsoincludes a classification module 210 for classifying care plan contentafter the care plans have been converted. Also as shown, thedigitization module 110 includes a standardization module 215 forstandardizing care plan content after the care plans have been convertedto a digital format.

Referring now to the standardization module 215, as will be described indetail below, the standardization module 215 includes a formattingmodule 220 for formatting healthcare plan content into a common format,a user input module 225 for receiving healthcare related informationfrom a users and patients, and a content selection module 230 forassociating content with one or more care plan.

Referring now to FIG. 3, a system diagram of an HMS 100 unificationsystem 300 is shown according to the present disclosure. As describedbelow, the unification system 300 includes a unification module 115. Theunification module 115 is used to merge one or more digitized care plansinto a unified care plan.

Also as shown, the unification module 115 is communicatively coupled toa database 135 and or external resources 301 such as a patient's medicalrecord data 305, known medical conflict data 310, and or medicalreference libraries 315. Using the information in the database and orexternal resources, the unification module 115 may identify potentiallyhazardous health care conflicts, and report the conflicts to one or moreusers.

Digitization, Unification, and Communication

The above discussion was primarily focused on HMS 100 components used toimplement the method for normalizing (i.e., digitizing and unifying),and communicating care plans. The below discussion will now focus on theprocess of normalizing and communicating care plans.

Referring to FIG. 4, an example of the HMS (100) process is shownaccording to the present disclosure. In one example, at step 405 the HMS(100) process digitizes one or more care plans if it is determined thatthe care plans are not in a common digital format. A care plan will bein a common digital format if the care plan is in a common digitalformat that is interpretable by the HMS (100).

Referring to the details of the digitization process in FIG. 5, if ithas been determined that one or more care plans are not in a commondigital format, the method digitizes the care plan content at step 500by converting the one or more care plans into a common digital format.This conversion process is performed by the digitization module (110)discussed above.

After converting the care plans into a common digital format at step500, the digitization process continues at step 505 by identifying oneor more tasks within each care plan. Health care tasks may be anycontent (e.g., instructions, etc.) directed to the management and ormaintenance of a patient's health.

Once the health care tasks have been identified, the digitizationprocess at step 510 determines whether the tasks are in a standardizedformat. A task will be in a standardized format if the task is in formatconsistent with the system's (100) task format settings. The system'stask format settings may be predefined or modified by a user of the HMS100.

After the digitization process determines that the tasks arestandardized at step 510, the digitization process classifies the tasksby associating with them one or more care plan tags. A care plan tag maybe task descriptive content or metadata that the system (100) can use toreadily interpret health care tasks. Task classification is implementedby the classification module (210).

As discussed above, if the digitization process determines that thehealthcare plan tasks have been standardized at step 510, thedigitization process will classify the tasks by associating them withtags. However if the digitization process determines at step 510 thatthe tasks have not been standardized, the non-standardized tasks arestandardized by the standardization module (215) described above.

FIG. 6 illustrates an example process for standardizing care plan tasks.At step 600, the standardization process standardizes one or more tasks.Standardizing tasks may include identifying numerical data within a taskof a plan and formatting the numerical data so that it is in standardform. Conversion settings are used during the standardization processfor indicating how to format the numerical data.

In one example, based on the numerical format settings, the formattingstep 600 of the standardization process detects user and or patientpreferences and or location data stored on the user's client device(145). Using this data, the HMS (100) formats the patient's health careplan content (e.g., care plan tasks) in a way that is consistent withthe patient's and or the user's preferences, location, and orgeographical customs.

In another example, instead of automatically detecting the location of auser and or patient from the location data located on the client device(145), the client device (145) may have a home setting that can beselected. In this example, regardless of the location data of thedevice, if the home setting has been selected, the patient's care planor health information will be formatted so that the patient or user mayview the care plan in a preselected language.

In addition to formatting tasks, at step 605 the standardization processallows the system (100) to receive input related to a patient's health.In one example, a user input module (225) is used to implement thisprocess. In this example, a user or the patient is allowed to give inputrelated to a patient's history of prior illnesses. The user input module(225) can receive input from the user and or the patient using amultiple choice query or other prompt that can be used to gatherimportant health information.

Referring to step 610, the standardization process associates contentwith one or more care plan tasks. In one example, this may be performedby the content selection module 230 discussed above. The associatedcontent may be educational in nature and may be related to one or morecare plan tasks. Once the content has been associated with a care plantask, a user and or patient may access the content during care plancommunication.

Returning to FIG. 4, after the digitization process (405) has digitizedthe one or more healthcare plans, including the classification andstandardization of the care plan tasks, the process continues at 410 byunifying the one or more care plans. In one example, the unificationprocess 410, implemented by the unification module (115) of theunification system (300) is used to combine the one or more care plansinto a unified care plan. In another example, the unification process410 identifies and flags task conflicts (e.g., conflicting medications,etc.) using care plan conflict data (310). In yet another example, theunification process 410 uses the HMS database (135) and or otherexternal resources (301) to provide content related to a patient's oneor more illnesses.

Referring to step 415 of FIG. 4, after the care plans have been unifiedinto a unified care plan, the care plan is communicated to one or moreusers and or patients using one or more communication mediums.Communication of the care plans is implemented using the communicationmodule (120). During the selection of the one or more communicationmediums, the communication module (120) may receive input related to auser and or patient's preferred communication type. In one example,after a communication medium has been selected, the process communicatesthe care plan directly to the user and or patient using thatcommunication medium.

FIG. 7 illustrates a block diagram of the HMS 100 of FIG. 1 according tothe present disclosure. As discussed above, the HMS 100 may beimplemented on one or more servers 105 having memory, one or moreprocessors, and at least one wired or wireless communication interface140 for establishing communications with one or more client devices 145.

The HMS 100 can be provided on an application service provider (ASP) orsoftware as a service (SaaS) model or otherwise hosted, as either asingle or multi branch configuration. Communication between clientdevices 145 and the servers is provided by the Internet, intranet, LAN,WAN or a combination of networks.

The application of the HMS 100 is hosted on a server system 105consisting of one or more computers in communication with each other,among them performing the functions of a database server 702, anapplication server 704 and a web server 706. Although, three separateserver computers are illustrated in FIG. 7, one or more server computersmay be used to implement the system.

During operation, each server will carry out different portions of theoverall functionality of HMS 100. For example, the application server704 may take requests from the web server 706, process data, and returnsresults back to the web server 706. The requests are usually datamanipulation requests and the application server 704 closely interactswith the database server 702 during data processing.

Referring to FIGS. 7A-7D, in the preferred embodiment, the applicationserver 704 includes server hardware 720 and storage 722, such as a harddisk drive or the like. The server hardware 720 includes a CPU orprocessor 721, RAM 723 and network interface (NIC) 725. Windows Serverfrom Microsoft is the preferred operating system 724 stored by thestorage 722. It is understood that this is exemplary and can evolve overtime to use different operating systems. The application server 704 alsoincludes, as part of its application software 726 stored on the storage722, an open data base connectivity (ODBC) server to enable receivedODBC compliant messages to be interpreted and executed by the databaseserver 702 and, additionally, to generate and transmit ODBC compliantmessages.

The web server 706 includes server hardware 740 (similar to serverhardware 720) and storage 742, which includes an operating system 746and web server hosting software 744 capable of receiving HTTP requests,receiving data posted to HTML or XML pages, interpreting receivedrequests, retrieving requested web pages (e.g., HTML or XML pages),transmitting retrieved pages and transmitting other data through use ofHTTP. In the preferred embodiment web server hosting software 744 isprovided using Microsoft IIS including the .NET framework, though it isunderstood that other web environments can be used.

The database server 702 includes server hardware 732 (similar to serverhardware 720) and storage 734, which includes an operating system 736and a database management system (DBMS) 738. The DBMS 738 in thepreferred embodiment is implemented using conventional SQL compliantrelational database management (RDBMS) software such as those availablefrom IBM, Microsoft, Oracle and the like. The DBMS 738 operates tocreate, maintain, update, query and otherwise control data stored on thestorage 734 in data tables, which form the database.

The storage 734, 722 and 742 are examples of computer readable medium ormedia having computer-executable instructions stored thereon foroperating the HMS 100 to perform method embodiments according to thepresent invention.

Each client 145 includes client hardware 760 (similar to server hardware720) and storage 762. In the preferred embodiment, the operating system764 of these clients 145 is a suitable version of Google Android, AppleiOS, or Microsoft Windows, though other operating systems can be used.The clients 145 in communication with server system hosting applicationhave client software such as a browser 766, i.e., Microsoft InternetExplorer in the preferred embodiment, though it is understood that otherbrowsers such as Chrome, Firefox, Opera, Safari, and the like can beused. The clients 145 have access to the HMS 100 via the network 708,which network can be the Internet, an intranet LAN or WAN connection ora combination.

The HMS 100 can be accessed by users and or patients using conventionalcomputers, workstations, hand-held devices, PDA's, smartphones, or otherclient devices 145. Each client device 145 also includes hardware, oneor more processors, and memory configured to communicate with the HMS100 through a network 708. The client devices 145 may communicate withthe server system 105 using software such as a web browser.

Referring to FIG. 8, example health care plans are shown according tothe present disclosure. In one example, one or more of the care plansmay be issued to a comorbid patient (i.e., a patient having one or moreco-occurring illness). For example, as shown, the first care plan 800may be derived from a physician or other health care professional for apatient having been diagnosed with high blood pressure and diabetes,while the second care plan 805 may be derived from a different physicianor care professional for the same patient. The second care plan may bederived for treating one or more additional illnesses (e.g., Alzheimer'sdisease and high cholesterol). However, it is not necessary for acomorbid patient to receive more than one care plan, as it is possiblefor a comorbid patient to receive a single care plan for treating two ormore co-occurring illnesses.

As shown, each care plan 800, 805 has within it one or more tasks. Forexample, one task as shown in the first care plan 800 directs thepatient to walk three miles and to take a certain blood pressuremedication. Also, examples of tasks in the second care plan 805 includedirecting the patient to do Pilates exercises and to take cholesterolmedication. As discussed above, the HMS 100 may be used to normalize oneor more of the first and second care plans of FIG. 8, by digitizing thecare plans if they are not in a common digital format, and unifying thecare plans by identifying and flagging potentially hazardous taskconflicts and by merging the care plans into a unified care plan forcommunication to one or more users and or patients.

Using the flow diagram of FIG. 9, and the first and second care plansdescribed above, an example process of normalizing and communicatingcare plans is illustrated. In one example, once the HMS (100) has beenexecuted on the server system (105), the process of normalizing healthcare plans begins by a user accessing the system and inputting one ormore of the care plans into the HMS (100) as shown at step 900. A usermay access the HMS (100) either through a computer or workstationdirectly communicating with the server system (105), or through theinternet (e.g., through a web portal) using one or more client devices(145).

After accessing the HMS (100), the one or more care plans are input intothe system (100). For example, in one example both the first care plan(800) and second care plan (805) are input into the system (100) byconverting the health care plans into a format suitable for electronicdocument exchange, such as portable document format (PDF) or otherformat. In addition, inputting the one or more care plan may also beperformed by integrating the HMS (100) with external resources such as apatient EHRs. This is because EHRs may have care plans that aretypically in an unstructured form e.g., unstructured notes written inMicrosoft Word. By integrating the HMS (100) with the patient's EHR suchas Epic or Allscripts, the system (100) can automatically import thecare plans/discharge notes and covert the care plans/notes into a moresuitable format.

Once the care plans are in a suitable format for exchange, they areuploaded to the HMS (100). In this aspect, the HMS (100) can allow theuser to browse for the health care plans and upload them to the HMS(100).

After the care plans have been uploaded into the HMS (100), at step 905the HMS (100) determines if the care plans are in a common digitalformat that is interpretable by the HMS (100). Determining whether thecare plans are in a common digital format includes determining if thereis any content within the care plans that is not in a digital format. Ifat least parts of the care plans are determined not to be in a digitalformat, a conversion process at step 910 is used to convert thenon-digital content into a digital form using conventional or adaptiveoptical character recognition (OCR) techniques known in the art.

In one example, one conventional OCR technique may be used to analyzetext to establish a typeface and font size, or other objects bycalculating for each word and for each of a plurality of possibletypefaces a scaling factor for matching a typeface construction of theword to the size of the word in the scanned electronic care plandocument. The OCR technique may then be used to analyze the variationsof the scaling factors for a particular typeface and identify whetherthe typeface is a good fit for reconstructing a plurality of the words.Other known OCR techniques may be used however to convert one or morecare plans into a digital format.

Once the care plans are in a digital format, at step 915 the individualcare plan tasks may be identified and or modified by a user. Accordingto one example, the HMS (100) identifies each word and compares eachword with known words or terms that are used to describe common taskswithin health care plans. For example, the HMS (100) may identify eachword in the task “drink 8 glasses of water” of the first care plan 800,and compare one or more of the words (e.g., “Drink,” “8 glasses,”“glasses,” and or “water”) of the task with a plurality of known systemtasks such as (“User action,” “64 oz goal,” “Measurement type [oz],”“Nutritional tag”), respectively.

When a number of compared words match, the care plan text may beidentified as a care plan task. Also, after the text has been identifiedat step 915, using the computer connected to the server system (105)described above, a user may use a keyboard or other input device tocorrect or modify care plan task content if necessary.

Once the care plans tasks have been identified at step 915, at step 920the HMS (100) determines if the tasks are in a standardized form. Asdescribed above, a task will be in a standard format if the task is informat consistent with the system's (100) task format settings (notshown). The system's task format settings may be stored in the HMS (100)database memory (135), and later accessed by the HMS (100). The taskformat settings may also be predefined or modified by a user of the HMS100 such as a physician or authorized family member.

The task format settings also include settings related to the preferredunits of measurement for converting quantitative data, preferredlanguage information, and or care plan task content association.According to the present disclosure, task content association settingsare settings used by the HMS (100) for determining whether to associatecontent with a care plan task during step 940 (discussed below).

In one example, the HMS (100) determines at step 920 that one or moretasks are not in a standardized form. In this example, a user may havepreset or modified the task format settings to indicate that the careplan tasks are to be formatted using the metric system. Given thisexample, the HMS (100) at step 925 will access the task format settings,determine that care plan tasks are to be formatted using the metricsystem, and convert the task in the first care plan 800 from “ounces” ofwater to “liters” of water. As another example, the settings may bemodified to allow logging data in one format, and viewing the log in adifferent format. This is especially useful in situations where, forexample, a patient may want to log their weight in pounds, but thephysician prefers to view the data in kilograms.

In another example, considering the task format settings indicate thatcare plan tasks are to be in a different language. According to thepresent disclosure, the preferred language may be set by the user in thetask format settings. One reason why language formatting settings can beset by a user is because some patients may visit physicians in othergeographical locations, often times receiving health care plans inlanguages other than the language the patient understands andcommunicates with. In this case, although a care plan may be received ina different language, the care plan may be translated into a preferredlanguage during care plan standardization.

Again referring to the first care plan (800), if the user in the exampleabove has set the language in the task format settings to Spanish, theHMS (100) at step 925 will access the task format settings, determinethat care plan tasks are to be formatted in Spanish, and convert thecare plan tasks from English to Spanish. Any language translator knownin the art may be used for this conversion process.

Referring now to step 930, the HMS (100) may determine that input isnecessary in order to complete the digitization process. In one example,some of the tasks to be performed by a patient may be based on certainfeedback received from the patient. For example, the second care plan(805) includes the task, “Exercise: Pilates for twenty minutes.”However, the task itself may exist in response to a questionnaire thathad previously asked the patient about the kinds of exercises thepatient typically likes to do.

Other examples may be that a patient's health condition at the time ofcare plan creation may be different than the patient's health conditionat the time of care plan normalization. For example, the patient mayhave previously given feedback that the patient was no longer in pain.The patient however may have given feedback incorrectly, due to notunderstanding a question inquired by a physician or the questionnaire ingeneral.

In one example, the HMS (100) will prompt a user and or patient forinput if the HMS (100) determines that user input may be necessary.Again using the first care plan (800) for purposes of illustration,after identifying the name or types of blood pressure and diabetesmedications in step 915, at step 935 the HMS (100) may prompt the userand or patient to select whether they have had adverse reactions to themedication types or dosages. If the user and or patient answers theprompt in the affirmative, the HMS (100) will flag the task related todirecting the patient to take the medication.

Further, using another example, based on patient feedback, the physicianmay not have instructed the patient to take a certain medication forpain. This could occur for example if the patient has answered a promptstating that the patient is not in pain. However, if the patientsubsequently provides input to the system (100) that the patient's levelof pain has later increased, the system (100) may flag the patient'scare plan indicating that the patient is in pain now.

In this and other aspects of the system (100), by using an alertcomponent, the system 100 will proactively alert/notify users such asnurses or physicians when this occurs. For example, the system (100)will alert a user and or flag the patient's care plan when certainsituations arise, such as when the patient indicates to the system thatthe patient is in pain.

In this scenario, the system (100) may be modified to alert when inputis received from the patient, or when user defined thresholds have beenreached relative to (levels of pain, etc.), side effects frommedications, or in response to vital readings such as increased bloodpressure, temperature, pulse, etc. Furthermore, the system (100) may bemodified to alert due to a specific input by the patient to the systemsuch as when the patient inputs an emergency response code like “HELP,”“911,” etc.

The alert component of the system (100) can be applied to any task typewithin the system (100), and the alert component may be modified byusers having permission to the patient's portal. For example, if thephysician or other user is monitoring the patient's care plan andreceives an alert, the user may update the care plan accordingly e.g.,to include one or more tasks directing the patient to take a certainmedication for pain, call for help, etc.

Referring now to step 940, after processing the input determination atstep 930, if the task format settings discussed above in step 925indicate that informational content is to be associated with one or moreof the tasks, at step 940 the HMS (100) will locate and associatecontent with one or more of the care plan tasks (e.g., information aboutthe exercises, food, medicine, etc. involved in the task) and if relatedcontent is found, associate the content with those tasks.

The HMS (100) will first determine that associated content exists. Forexample, after identifying the tasks in the first or second care plan(800 or 805) the HMS (100) will query database (135) for key wordssimilar to words identified in the one or more tasks described in step915. If one or more documents or content having a threshold number ofthe identified words exists in the database (135), the HMS (100) willcreate a link (e.g., hyperlink) to that content and append the link orthe document to the care plan having that task. The HMS (100) mayadditionally query content using the internet or other external resource(301).

In one example implementation of the above process at step 940, the HMS(100) may send a search query from the server system (105) to a websearch engine server with a server system (105) search index attached tothe search query. The search query will contain a list of key words orphrases related to each task, and will report back to the server system(105) the results of the search.

For example, referring to the diabetes medication in the first care plan(800), the HMS (100) may send a search query to a web search engineserver to locate key words similar to the name of the diabetesmedication. If any results matching the name of the diabetes medicationare returned, the HMS (100) will associate the results (i.e., link to anarticle, website, etc.) with the task.

In another example referring to the second care plan (805), using asimilar process, the HMS (100) may associate information related to thebenefits of Pilates exercises, etc. Other content association methodsmay also be used, such as associating metadata with one or more tasks.The associated metadata can be the frequency that the task is to beperformed, the time of day that the task is to be performed, and whenthe task will expire and will no longer need to be performed. Further,the metadata can be associated educational content, the type of the task(e.g., exercise based or nutritional based), the expected response(e.g., oz, lbs., etc.), or the alert thresholds described above.

In one example, content metadata may be associated with a care plan orcare plan tasks using a document processing system that allows embeddingmetadata in digital documents, or other document processing systemsknown in the art. Using this example, and referring to the taskinstructing a patient to take diabetes medication in the first care plan(800), instead of associating a link to an article or informationassociated with the diabetes medication, the content and or link may beembedded in the care plan document as metadata.

At step 945, the HMS (100) classifies tasks that are in a common digitalformat and that have been standardized. Although the illustrations abovemay have involved first digitizing and standardizing the first andsecond care plans, if the care plans are initially in a common digitalform (i.e., the “YES” path through step 905) and are initially in astandardized form (i.e., the “YES” path through step 920), the HMS (100)will classify the care plans at step 945.

The HMS (100) classifies tasks by associating with them one or moretags. The tags that are used to classify the tasks are independent ofthe care plan and the metadata associated with each task such as theeducational content, the type of the task, etc. as described above, andinstead exist to enable a programmatic approach to standardizing andassembling care plans from the system's (100) perspective.

In one example, during classification, a tag may be metadata that theHMS (100) will use to more readily interpret care plan tasks. Forexample, one or more tags may be assigned to a care plan task by usingthe task terms that were identified in step 915. The tags may beembedded within the care plan using the document processing settingsdescribed in reference to step 940 above.

Using the first care plan 800 as an example, one or more identifiedwords may be associated with predefined HMS (100) tags. For example, oneor more words of the task “drink eight ounces of water” of the firstcare plan 800 may be identified at step 915. These identified words areused during classification at step 945 by associating one or more taskwords with metadata. The metadata may be descriptive in nature, and maydescribe the task as generally related to instructing a patient to drinksome amount of liquid.

After the digitization process of FIG. 9, as shown in the flow diagramof FIG. 10, the HMS (100) will unify the one or more care plans into asingle unified care plan. The unification process first begins byremoving duplicate tasks. Because task titles may be in differentlanguages or written in a different way e.g., “Drink Water” vs. “Drink48 oz of Water,” the system strongly relies on the tasks' meta data. Forexample, task titles that have the same fingerprint i.e., title, type,format, and tag are unified into one. However for tasks that are notexact, yet closely related e.g., “Drink Water” vs. “Drink 48 oz ofWater,” the system will prioritize the tasks in the order of taskshaving defined alert thresholds, goal-oriented tasks, and tasks thatrequest ‘structured’ data responses e.g., logging 48 oz of water isbetter than a yes/no response.

In another example, a duplicate task may be a task that is listed inmore than one care plan, or listed more than once in the same care plan.In this example, the duplicate tasks may have been identified duringstep 915. However, using document processing applications describedbelow, the HMS (100) will remove these duplicates from the unified careplan.

For removing duplicate tasks, the system (100) at step 1000 firstinspects a patient's profile and identities which care plans are beingmerged. The system will analyze a patient's profile for care plans thathave been selected for merging. Care plans may be selected for mergingby a user of the system at digitization.

After the system identifies the care plans to be merged, at step 1005,the system (100) removes the purely duplicate master tasks and createsone reference task for the duplicates. In order to remove the pureduplicates, a simple character search may be performed on the mastertask strings for each of the care plans. Character string search andrecognition can be performed using character recognition documentprocessing applications such as those used in Microsoft Word or Adobedocument processing systems as known in the art. Once the duplicatecharacter strings have been identified at step 1005, they may beconsolidated by the system (100) into a single reference task.

Also at step 1010, the system (100) identifies tasks that aren't exactduplicates, but are similar, based on their meta data and analyzes themetadata to determine which tasks will provide the most data. Forexample, given three similar tasks in three different care plans: “Drinkwater,” “Drink 48 oz of water,” and “Drink 64 oz of water.”

If the metadata associated with the first task “Drink water” is directedto a simple (True/False) query of the patient e.g., merely prompting thepatient to answer whether or not the patient has taken water for theday, that task may not will not be considered by the system as providingmore data than e.g., the second task “Drink 48 oz of water,” havingmetadata that requires a numeric response from a patient e.g., promptingthe patient to enter the amount of water the patient has taken given a48 oz goal.

Likewise, the third task “Drink 64 oz of water” may be considered toprovide the most data than both the first and second tasks if the thirdtask requires a numerical response (as described above), and alsoprovides educational content to a patient such as information related towhy drinking water is important given the patient's diagnoses. After thesystem (100) identifies and analyzes the tasks that are similar at step1010, the system (100) consolidates the similar tasks into one referencetask at step 1015. For example, the consolidated task may state, “Drink64 oz of water today,” having metadata that requires a numeric responsegiven 64 oz goal and have associated educational content.

After consolidating the duplicate tasks, the system (100) at step 1020establishes data links between the reference tasks, the original mastertasks, and originating care plan for interoperability across disparatesystems. For example, a user that provides the first care plan may checkthe patient's portal (125) to see that the patient drank water. Because,that particular care plan's task “Drink water” was consolidated into thetask, “Drink 64 oz of water today,” the system will include additionalnotes stating that the patient drank an amount of 64 oz of water. Theusers who administered the second and third care plans will obtainsimilar information through the patient's portal (125).

Once all existing task duplications have been determined and removed andor flagged, the HMS (100) will determine if there exist any taskconflicts at step 1025. Task conflicts may be hazardous to a patient, ormay simply be conflicting instructions that are impractical for apatient to execute.

Medication based tasks are queried against a 3^(rd) party database ofknown reactions to identified patient risks. Further, in other casescare plans may have conflicting advice given surrounding a patient'streatment. For example, a diabetic patient suffering from knee pain mayhave his chronic disease coach suggest he run daily, while his physicaltherapist suggest he only walk and do light stretches. In either case,care plans having conflicts are flagged for clinical review andresolution.

For example, considering different physicians give a patient the firstand second care plans (800 and 805) described above. At step 1025 theHMS (100) will compare each identified task within each care plan, andalso compare each identified task with the tasks that have beenidentified within other care plans (if multiple care plans are beingmerged) for determining conflicts.

In one illustration, the HMS (100) at step 1025 will compare the typesof diabetes and blood pressure medications the patient has been directedto take per the first care plan (800). The HMS (100) may then query thedatabase (135), care plan conflict data (310) and or other externalresource (301) (such as the internet, etc.) using a search query orother method, and determine whether or not potential conflicts existswith taking both of these medications.

In another example, the HMS (100) may compare the identified task “walkthree miles” in the first care plan (800) with the identified task“Exercise: Pilates for twenty minutes” in the second care plan (805). Ifthe instructed times for exercising are at the same time (e.g., if thecare plans direct the patient to do both tasks at 1:00 pm), the HMS(100) may detect the times as being the same, and flag one or more ofthe tasks as having a conflict at step 1030.

If the tasks identified above are flagged as having a conflict, the HMS(100) may indicate to the user that there exists a conflict in theunified care plan e.g., the HMS (100) may indicate a conflict next tothe task “walk three miles,” “***conflict with Pilates exercise at 1:00pm***.” Upon noticing the conflict, a user (preferably a physician orhealth care provider) may modify the unified care plan (as discussedbelow) to remove the conflict.

Once all existing conflicts have been determined and flagged, or if theHMS (100) queries and finds that no potential conflicts exist, the HMS(100) will merge the one or more care plans at step 1040. In order tomerge the care plans at step 1040, the HMS (100) will reorganize eachtask from the one or more collective care plans and any reference tasksinto a single care plan. The HMS (100) may reorganize tasks using thedocument processing application described above, which may be used tomodify or extract the task data including associated content,classification tags, and or other metadata for each of the care plantasks, and append the task data to a single care plan document.

Referring now to FIG. 11, once the one or more care plans have beenunified, the unified care plan will be communicated to a patient. Atstep 1100, the care plan content to be communicated will first bescheduled. In one example, the unified care plan at step 1010 willinclude all tasks associated with a physician's instructions. Byscheduling the content of the unified care plan, the care plan taskswill be delivered to a patient on a scheduled basis.

For example, a unified care plan may contain a task directing a patientto “take cholesterol medication three times a day,” or “exerciseregularly.” As these are general tasks, a patient may not know if takingthe medication three times before breakfast would satisfy the firsttask, or if exercising for 30 minutes every month would satisfy thesecond task. Thus, the HMS (100) may take the tasks within the unifiedcare plan and schedule the tasks so that scheduled care plans aredelivered to the patient on a regular basis.

In one example, scheduling the tasks will be performed by the HMS (100)by using user defined settings. Stored in the database (135) or othermemory within the server system (105), user defined settings indicatehow general tasks are to be scheduled. For example, considering the taskabove requiring a patient to exercise regularly. The HMS (100) mayidentify this as a general task, and use the user defined settings toschedule the task.

Using this example, if the user defined settings indicate to the HMS(100) that the above task should be scheduled for directing a patient toexercise at least three times per week, the HMS (100) may schedule thepatient's communicated care plan accordingly. The same user definedsettings may apply for scheduling the time intervals for directing thepatient to take medication. However, the system (100) may also obtaininformation regarding the type of medication and suggested times fortaking the medication from the database (135), user, or other resourcesuch as the internet as described above.

Referring to step 1105, after the care plan content has been scheduled,the HMS (100) determines whether or not a user has selected a medium forcommunication. Care plans are communicated, including any associatedmetadata, using at least one communication medium (e.g., email, textmessaging, web portal, interactive video, or through the use of anyother digital communication device). In one example, if the HMS (100)determines that no communication medium has been selected, the HMS (100)will prompt a user and or patient in order to receive input regardingthe selection of one or more communication mediums at step 1110. Thisinput may include the communication medium (i.e., email, text messaging,etc.) along with the associated communication medium contact informationsuch as an email address or phone number.

After one or more communication mediums have been selected, at step 1115the HMS (100) may again prompt the user for any additional modificationsof the care plan before the HMS (100) communicates the care plan to thepatient. In one example, if the user selects that the care plan is to bepersonalized, at step 1120 the user will be given the opportunity tomodify one or more of the contents, color, font, contrast, sound,orientation, metadata, or style associated with the unified care plan.

The HMS (100) will use the user's input to modify document processingsettings associated with the document processing system described above.For example, if the settings were modified to indicate that the color ofthe care plan should be changed from white to red, the documentprocessing system will change the color of the care plan accordinglybefore the HMS (100) communicates the care plan to the user. Themetadata such as sound, duration, and frequency associated with areminder or associated content may be modified in a similar manner.

If however, the care plan to be communicated has been personalized bythe user at step 1120, the care plan at steps 1125-1130 will againidentify potential conflicts and flag the potential conflicts if anyexist. Steps 1125-1130 are similar to steps (1000-1005) discussed above,and serve to flag conflicts that may have been introduced by a userduring care plan personalization at step 1120. Once all conflicts havebeen identified and flagged, or if the care plan has not beenpersonalized by the user (see “No” path through step 1115) the care planwill be communicated to a user and or patient using the selectedcommunication medium.

For example, if a user at step 1110 has selected to receive care plancommunication through email, the HMS (100) will send the care plan tothe user's email address. In another example, if a patient at step 1110has selected to receive communication through the web portal (125), theHMS (100) may host a webpage using the server system (105), allowing thepatient to log into and access care plan information stored on the HMS(100) database (135) or other server system (105) memory. Using thisexample, the HMS (100) may communicate a website link or universalrecord locator (URL) with the user via email or other method so that thepatient may access the care plan information.

FIG. 12 illustrates an example unified care plan that has been accessedthrough a web portal (125) using a client device 145 according to thepresent disclosure. As shown, the client device 145 may be a digitaldevice such as a PDA, cellular phone, or other device. As describedabove, a user or patient may use a client device 145 to access one ormore care plans through a web portal (125). Also, the client device 145may display the contents of a care plan using a GUI interface. In thisexample, through the GUI interface a user and or patient may accesscontent related to a care plan, modify the care plan, and or otherwisegive input through the GUI interface.

Also, for some patients, because the severity of their disease ortreatment can make simple physical and/or mental activities nearlyimpossible, the system (100) may allows a user such as family member orfriend to log any information on behalf of the patient using thepatient's web portal or dashboard (125). In other cases, the familymember or friend can be allowed to monitor their loved one's medicalinformation from across the globe.

As shown in FIG. 12, the GUI interface indicates that Patient A's careplan currently directs Patient A to perform three tasks on the morningof Dec. 1, 2014. Also as shown are input boxes that may be checked atthe time each of the tasks have been completed. Checking the boxes mayprovide feedback to the HMS (100) regarding the patient task updates.For example, if the box associated with a first task does not getchecked, the care plan may send a reminder regarding that task in theafternoon and or evening. However, if a task is checked as completed,the database (135) will update the care plan scheduled content and noreminder will be sent.

As another example, as shown at the bottom of the client device 145display in FIG. 12, associated content as discussed above may bepresented on the client device 145. The associated content may beeducational in nature and may contain links to other resources that maybe located on other servers such as web servers, etc., externalresources (300), or databases (135).

Referring now to the example in FIG. 13, a reminder is shown remindingPatient A to walk for 30 minutes, or to remind a user such as a healthcare professional or loved one that Patient A has not walked for 30minutes that day. In another example, as shown in the reminder window ofthe client device 145 in FIG. 13, a weather warning or other warning maybe shown. Weather, road conditions, and potentially hazardous patienthealth information may be obtained from the client device 145, theserver system (105), internet, or other resource described herein.

Also as shown in the bottom of the client device 145 display in FIG. 13,the GUI interface may allow the user and or patient to input progressinformation such as how much water intake the patient has recorded forthe day. In yet another example, the system (100) may give positivefeedback through the GUI interface, or other communication medium, basedon care plan feedback received from one or more users and or patients.

Referring now to FIGS. 14A-14B, additional examples of health care plansare illustrated according to the present disclosure. As shown, theexample care plan 1400 shown in FIG. 14A is for a patient who has beendirected to take the medication Tysabri. The drug Tysabri® (natalizumab)is a prescription medicine used to treat patients having relapsing formsof Multiple Sclerosis (MS). Also, the example care plan 1405 shown inFIG. 14B is for patients who have been directed to take the medicationRemicade®, which is used to treat Crohn's Disease and othergastrointestinal disorders.

The operation of flow charts of FIGS. 9, 10, and 11 using the above careplans is as follows. In a first example using the care plan 1400, oncethe HMS (100) has been executed on the server system (105), the processof normalizing health care plans begins by a user accessing the systemand inputting one or more of the care plans (1400, 1405) into the HMS(100) as shown at step 900. A user may access the HMS (100) eitherthrough a computer or workstation directly communicating with the serversystem (105), or through the internet (e.g., through a web portal) usingone or more client devices (145). As described above however, it is notnecessary for a user to input the care plans, as the system (100) canautomatically import the care plans/discharge notes into the system(100) by integrating the HMS (100) with the patient's EHR such as Epicor Allscripts.

After accessing the HMS (100) and inputting or importing the care plan1400, care plan 1400 is automatically converted into a format suitablefor electronic document exchange, such as portable document format(PDF), Microsoft Word document (.doc), or other exchange format. Once ina suitable format for exchange, the care plan 1400 is uploaded to theHMS (100) for processing. In this aspect, the HMS (100) can allow theuser to browse for additional health care plans and upload them to theHMS (100) if desired.

After the care plan 1400 has been uploaded into the HMS (100), at step905 the HMS (100) determines if the care plan is in a common digitalformat that is interpretable by the HMS (100). At step 905, the system(100) determines that the care plan 1400 is not in a digital format. Atthis point, a conversion process is initiated at step 910 and is used toconvert the non-digital content of the care plan 1400 into a digitalform. In order to do so, an adaptive optical character recognition (OCR)application is executed and performs character recognition on the careplan 1400 to convert the care plan 1400 into a digital format.

Once the care plan 1400 is in a digital format, at step 915 the careplan tasks e.g., tasks 1-11 of care plan 1400 are identified and ormodified by a user. The HMS (100) identifies each task by identifyingeach word and comparing each word with known words or terms that areused to describe common tasks within health care plans. Once the careplans tasks have been identified at step 915, at step 920 the HMS (100)determines if the tasks are in a standardized form. Because the system(100) recognizes that a task will be in a standard format if the task isin format consistent with the system's (100) task format settings, thesystem at step 920 retrieves the task format settings from the HMS (100)database memory (135).

After determining that the task format settings sets units ofmeasurement for converting quantitative data to Fahrenheit (° F.) fortemperature and pounds (lbs) for weight, at step 920 that tasks 1 and 2of care plan 1400 are not in a standardized form. After making thisdetermination, the HMS (100) at step 925 will convert the values fortemperature and weight of tasks numbered 1 and 2 to Fahrenheit (° F.)and pounds (lbs), respectively. The system (100) at step 920 will alsoconvert future values input in response to the tasks as Fahrenheit (°F.) and pounds (lbs), respectively.

Referring now to step 930, after standardizing the care plan 1400 tasksthe HMS (100) determines that no input is necessary in order to completethe digitization process. At step 940, based on the task format settingsdiscussed above in step 925, the system determines that informationalcontent is to be associated with task 7. After making thisdetermination, the HMS (100) determines that associated content existsby performing a query of the database (135), internet, and externalresources (301) for key words that are similar to words identified intask 7. The system further locates content that has a threshold numberof identified words related to the medication Tysabri in database (135),creates a link (e.g., hyperlink) to that content, and appends the linkor the document within the metadata of task 7.

After associating content with task 7, at step 945 the HMS (100)determines that all of the tasks in the care plan 1400 are in a commondigital format and are in a standardized form. At step 945 based on theterms identified in task 3 of care plan 1400, the HMS (100) classifiestask 3 of care plan 1400 “Drink 48 oz of water” by associating metadatawith the tags “nutritional,” “yes/no,” “water intake.” The systemclassifies the remaining tasks of care plan 1400 similarly, byassociating one or more tags with each of the tasks based on identifiedterms of the task. As discussed above, the tags are independent of thecare plan metadata associated with each task such as the associatedcontent, the type of the task, etc.

After the digitization process illustrated in FIG. 9, referring to FIG.10, the HMS (100) unifies care plan 1400. The unification process beginsby removing duplicate tasks. The system (100) at step 1000 firstinspects a patient's profile and identities care plan 1400 is the onlycare plan to be merged. After identifying the care plans to be merged,at steps 1005 and 1010 the system (100) determines that there aren't anypure duplicate or similar tasks, and skips the consolidation process atstep 1015.

The system (100) at step 1020 continues by determining that there aren'tany consolidated reference tasks and proceeds to step 1025 to determineif task conflicts exists. In determining conflicts, the system (100) atstep 1025 compares the types of medications the patient has beendirected to take per the care plan (1400), and queries the database(135), care plan conflict data (310), and or other external resources(301) (such as the internet, etc.) using a search query as describedabove to determine if there are any conflicts. At step 1025, the systemdetermines that the drug Tysabri® (natalizumab) is a prescriptionmedicine used to treat patients having relapsing forms of MultipleSclerosis (MS), and is not in conflict with any other prescribed drugsin the care plan 1400.

After the HMS (100) queries and determines that no conflicts exist, theHMS (100) merges care plan 1400 at step 1040. To this end, using thedocument processing application described above, the HMS (100)reorganizes each task in care plan 1400 with reference tasks. However,because the system (100) did not identify any reference tasks above atstep 1025, the HMS (100) continues by appending the task data to asingle care plan document as shown in reference to FIG. 15, and asdiscussed below.

Referring now to FIG. 11, as described above, once the system (100)merges the care plan 1400 into a unified care plan (see FIG. 15), theunified care plan will be communicated to the patient and or user.However before being communicated, the system (100) will schedule eachtask within the care plan. As described above, by scheduling the contentof the unified care plan, the care plan tasks will be delivered to apatient on a scheduled basis.

For example, the unified care plan of FIG. 15 may contain a taskdirecting a patient to “Take a single dose of Tysabri.” At step 1100,the system reads the user defined settings stored in the database (135)or other memory within the server system (105), and determines thescheduling preferences for the task instructing the patient to take themedication Tysabri to be once per month on the first day of the month.The HMS (100) subsequently schedules this task to prompt the user totake the medication on the first day of each month.

After each of the tasks have been scheduled at step 1100, at step 1105the HMS (100) determines whether or not a selected a medium forcommunication has been selected. Using this example, because acommunication medium has not been selected, the HMS (100) prompts theuser and or patient to input a preferred communication medium i.e.,email, text messaging, web portal (125) etc., as described above.

After receiving input that the communication medium has been selected asweb portal (125), the HMS (100) at step 1115 prompts the user foradditional modifications of the care plan before communicating the careplan to the patient. Again using this example, the user selects at step1120 that the unified care plan of FIG. 15 is to be personalized bydelineating each task with bullets instead of numbering each task. Theuser's input is used to modify the document processing settingsassociated with the document processing system described above, and HMS(100) at step 1135 will modify the unified care plan based on theupdated settings before communicating the care plan to the user.

After personalization however, at step 1120 the care plan of FIG. 15again identifies potential conflicts and flags the potential conflictsif any exist. After determining at step 1125 that no hazardous conflictsare present, or that the care plan has not been personalized by the user(see “No” path through step 1115) the system (100) communicates the careplan by hosting a webpage at step 1135 using the server system (105),that allows the patient to log into and access the care plan informationshown in FIG. 15.

Referring now to FIG. 15, an example of a unified care plan based on thecare plan of FIG. 14A is illustrated. The unified care plan is accessedthrough a web portal (125) using a client device 145 as discussed above.The client device 145 may be a digital device such as a PDA, cellularphone, or other device. The client device 145 may display the contentsof a care plan using a GUI interface, where the patient and or user mayaccess content related to a care plan, modify the care plan, and orotherwise give input through the GUI interface.

As shown in FIG. 15, the GUI interface indicates that Patient A'sunified care plan directs Patient A to perform tasks in the afternoon ofDec. 1, 2015. Also, using a touch screen display, as is known in theart, each task may be accessed by touching that task on the display ofthe client device 145 to either provide input to the system (100)regarding that task, such as when the task has been completed by thepatient. Also as shown, the system (100) has standardized thetemperature and weight values in the unified care plan from Celsius (°C.) and Kilograms (kg), as shown in care plan 1400 of FIG. 14A, toFahrenheit (° F.) and pounds (lbs), respectively. Also, the system (100)has associated content with the task directing the patient to take a“single dose of Tysabri.” For example, by touching or selecting theunderlined word “Tysabri” (e.g., the hyperlink) in the unified careplan, the associated website containing information related to themedication can be accessed by the user and or patient.

Now that an example of the system and method for normalizing andcommunicating care plans using just a single care plan has beendescribed, an example of the system and method using both the third andforth care plans, 1400 and 1405, respectively, will now be described. Asdiscussed above with reference to FIG. 14A, once the HMS (100) has beenexecuted on the server system (105), the process of normalizing healthcare plans begins with accessing the system and inputting or importingcare plans 1400 and 1405 into the HMS (100).

After accessing the HMS (100) and inputting or importing the care plans1400, 1405, as described above, the care plans are automaticallyconverted into a format suitable for electronic document exchange. Oncein a suitable format for exchange, the care plans 1400 are uploaded tothe HMS (100) for processing.

After the care plans 1400, 1405 have been uploaded into the HMS (100),at step 905 the HMS (100) determines if each care plan is in a commondigital format that is interpretable by the HMS (100). At step 905, thesystem (100) determines that the care plan 1400 is not in a digitalformat, but that care plan 1405 is in a digital format. At this point, aconversion process is initiated at step 910 and is used to convert thenon-digital content of the care plan 1400 into a digital form. Thesystem at step 910 then executes an adaptive optical characterrecognition (OCR) application and performs character recognition on thecare plan 1400 to convert the care plan 1400 into a digital format.

Once the care plan 1400 is in a digital format, as discussed in theabove example using only care plan 1400, at step 915 the care plan tasksof both care plan 1400 and 1405 are identified by the system (100). Oncethe care plans tasks have been identified at step 915, at step 920 theHMS (100) determines if the tasks are in a standardized form, andretrieves the task format settings from the HMS (100) database memory(135) in order to make the determination.

After determining that the task format settings require units ofmeasurement for converting quantitative data to Fahrenheit (° F.) fortemperature, and pounds (lbs) for weight, at step 920 each task of careplans 1400 and 1405 are evaluated. After making the determination, thatat least some of the tasks are not in a standardized form (i.e., notspecific to Fahrenheit (° F.) and pounds (lbs), for temperature andweight, respectively), the HMS (100) at step 925 converts thetemperature and weight values of the tasks to Fahrenheit (° F.) andpounds (lbs), as shown in the unified care plan of FIG. 16.

Referring now to step 930 of FIG. 9, after standardizing each of thecare plan's (1400, 1405) tasks the HMS (100) determines that user inputis necessary in order to complete the digitization process. As describedabove at step 915, the system (100) identifies tasks by identifying eachword of the tasks and comparing each word with known metadata tags orterms that are used to describe common tasks within health care plans.In this example, the system (100) identifies the task in care plan 1405that directs the patient to complete a Tuberculosis skin test. Forexample, the term “Tuberculosis” of the care plans is compared with themetadata tag “TB skin test” saved in the database (135), and isidentified as a Tuberculosis test.

At step 930 of FIG. 9, the metadata associated with this task directsthe system (100) to display a prompt to the user requesting inputregarding whether the patient has previously had an allergic reactionafter receiving skin tests of this type (see FIG. 17). As describedabove, prompts may be displayed and input received via the HMS (100)either through a computer or workstation directly communicating with theserver system (105), or through the internet (e.g., through a webportal) using one or more client devices (145). After receiving theuser's response that the patient has not had an allergic reaction tothis test, the system (100) refrains from flagging the task for userreview, and continues to step 940.

At step 940, based on the task format settings discussed above in step925, the system determines that informational content is to beassociated with task 7 of care plan 1400 “Take single dose of Tysabri,”and task 6 of care plan 1405 “Take single dose of Remicade.” Aftermaking this determination, the HMS (100) determines that associatedcontent exists by performing a query of the database (135), internet,and external resources (301) for key words that are similar to wordsidentified in each task. The system further locates content in database(135) that has a threshold number of identified words related to themedications Tysabri and Remicade, creates a link (e.g., hyperlink) tothat content, and appends the link or the document within the metadataof each respective task.

After associating content with each task, at step 945 the HMS (100)determines that all of the tasks in each care plan 1400, 1405 are in acommon digital format and are in a standardized form. At step 945 basedon the terms identified in task 3 of care plan 1400, the HMS (100)classifies task 3 of care plan 1400 “Drink 48 oz of water” byassociating metadata with the tags “nutritional,” “yes/no,” and “waterintake.” The system (100) classifies the tasks of care plan 1405similarly, by associating one or more tags with each of the tasks basedon identified terms of the task. As discussed above, the tags areindependent of the care plan metadata associated with each task such asthe associated content, the type of the task, etc.

After the digitization process illustrated in FIG. 9, referring to FIG.10, the HMS (100) unifies care plans 1400 and 1405 into one unified careplan. The unification process begins by first removing duplicate tasks.The system (100) at step 1000 inspects the patient's profile andidentities two care plans (i.e., care plans 1400 and 1405) are to bemerged. After identifying the care plans to be merged, at steps 1005 and1010 the system (100) identifies the pure duplicate tasks at step 1005.

By parsing the character strings of the tasks in each care plan 1400,1405, the system (100) identifies that the task “Are you takingantibiotics” exists in both care plans. The system also identifies thetask “Record mood” as being similarly duplicated in each care plan.After identifying the pure (i.e., duplicate tasks), the system (100)consolidates the duplicate tasks by creating a single reference task foreach of the tasks, using the character string of each of the tasks. Forexample, the four duplicates described above are replaced with tworeference tasks having the character strings “Are you takingantibiotics” and “Record mood.”

However, the system (100) will not replace pure duplicate tasks in caseswhere the character strings of the tasks are the same, but the metadataof the tasks are different. For example, both care plans (1400, 1405)have the task “set next appointment reminder.” However, although eachtask will have the exact same character string during identification atstep 915, due to the identified type of the task (e.g., “appointmentmodification”) the metadata associated with each task will be specificto each care plan. Such metadata will contain detail such as thephysician associated with creating that care plan, etc.

As a result, after identifying the duplicate task “set next appointmentreminder,” the system (100) will not consolidate the duplicate tasks bycreating a single reference task for each of the tasks; instead, thesystem (100) will create both tasks in the final care plan as shown inFIG. 16. As shown in FIG. 16, each task may also have a suffixindicative of the task's respective care plans. For example, consideringcare plan #3 (1400) was created by the physician, “Dr. A,” the task thatderived from care plan #3 (1400) will have a suffix indicating that thepatient's reminder is to set an appointment with that particular doctore.g., “Dr. A.” Likewise, the task deriving from care plan #4 (1405) willhave a similar suffix.

At step 1010, the system (100) identifies tasks that aren't exactduplicates, but are similar based on task meta data. The system (100)identifies that the task “Drink 48 oz of water” in care plan 1400, andthe task “Drink 48 ounces of water” in care plan 1405 share the similarmetadata “nutritional,” “yes/no,” and “water intake.” Based on thisanalysis, the system (100) determines that the tasks are similar, and atstep 1015 consolidates the task into a single reference task.

However, because the tasks are not exact duplicates, the systemconsolidates the tasks by determining which task will provide the mostdata. Because each of the above tasks will provide the same amount ofdata (i.e., in response to either task a yes/no response will bereceived, no informational content is associated with either task,etc.), the first task string processed by the system (100) will be usedas the reference task (i.e., “Drink 48 oz of water”). The systemprocesses the remaining similar tasks as described above, and continuesto step 1020.

After consolidating the duplicate tasks, the system (100) at step 1020establishes data links between each of the reference tasks, the originaltasks, and originating care plan. At step 1025 the system determines iftask conflicts exists. In determining conflicts, the system (100) atstep 1025 compares the types of medications the patient has beendirected to take per the care plans 1400, 1405, and queries the database(135), care plan conflict data (310), and or other external resources(301) (such as the internet, etc.) to determine if there are anyconflicts.

At step 1025, the system determines that the drug Tysabri®(natalizumab), of care plan 1400 is a prescription medicine used totreat patients having relapsing forms of Multiple Sclerosis (MS), and isin direct conflict with the drug Remicade® of care plan 1405, that isused to treat Crohn's Disease and other gastrointestinal disorders. Thesystem (100) further detects the task “take a single dose ofHydrochlorothiazide” and determines that the drug Hydrochlorothiazide isnot in conflict with either of the drugs Tysabri® or Remicade®.

After the HMS (100) queries and determines that conflicts exist, the HMS(100) flags each task for review and after the conflict has beenresolved by a user (i.e., doctor, nurse, etc.) the resolution will bereflected in the unified care plan (shown in FIG. 16). After the system(100) detects a conflict between the medications Remicade® and Tysabri®at step 1025 of FIG. 10, at step 1030 the system will flag each taskwhich contains those drugs for review. After the tasks have beenflagged, the system (100) at step 1035 will prompt the user for inputrelated to the conflict, either through a computer or workstationdirectly communicating with the server system (105) as described above,or through the internet (i.e., through the patient's web portal).

When the system (100) prompts the user at step 1035, the user willprovide input to the system (100) to resolve the conflict, either byselecting one of the conflicting medicines, changing a particularmedication, or by removing all of the conflicting medicines from thecare plans. In any of the above resolutions, the user will likelycontact the physicians and or necessary parties before modifying careplans. At step 1035, the user provides input to the system to remove thetask instructing the patient to take the medication and Remicade®. Afterthe conflict has been resolved, the conflict resolution will bereflected in the unified care plan. As shown (shown in FIG. 16), thetask related to taking the drug Tysabri® has been included in theunified care plan, while the drug Remicade® has been removed. Also asshown, the drug Hydrochlorothiazide has also been included in theunified care plan (FIG. 16), as it was not in conflict with the othermedications.

After all conflicts have been resolved, at step 1040, using the documentprocessing application described above, the HMS (100) reorganizes eachtask in care plan 1400 using the reference tasks and non-consolidatedtasks. The HMS (100) continues by appending the task data to a singlecare plan document as shown in FIG. 16. Referring now to FIG. 11, asdescribed above, once the system (100) merges the care plans 1400, 1405into a unified care plan (FIG. 16), the unified care plan will becommunicated to the patient and or user.

However, as described above with reference to the unified care plan ofFIG. 15, before being communicated the system (100) will schedule eachtask within the care plan. By scheduling the content of the unified careplan, the care plan tasks will be delivered to a patient on a scheduledbasis. After each of the tasks have been scheduled at step 1100, at step1105 the HMS (100) determines whether or not a selected a medium forcommunication has been selected.

After receiving input that the communication medium has been selected asweb portal (125), the HMS (100) at step 1115 prompts the user foradditional modifications of the care plan before communicating the careplan to the patient. The system at step 1115 receives input from a userthat additional modifications are not necessary, and at step 1135 thesystem (100) communicates the care plan by hosting a webpage using theserver system (105), that allows the patient to log into and access thecare plan information shown in FIG. 16.

Referring now to FIG. 16, an example of a unified care plan based on themerged care plans of FIGS. 14A and 14B is illustrated. The unified careplan is accessed through a web portal (125) using a client device 145 asdiscussed above. The client device 145 may be a digital device such as aPDA, cellular phone, or other device. The client device 145 may displaythe contents of a care plan using a GUI interface, where the patient andor user may access content related to a care plan, modify the care plan,and or otherwise give input through the GUI interface.

In this case, the screenshot was taken a day before the patient's nexttreatment so only a subset of the tasks are shown. Using a touch screendisplay, each task illustrated in the care plan of FIG. 16 may beaccessed. As shown, the system (100) has standardized the temperatureand weight values in the unified care plan from Celcius (° C.) andKilograms (kg), as shown in care plan 1400 of FIG. 14A, to Fahrenheit (°F.) and pounds (lbs), respectively. Also as shown, the system (100) hasremoved the hazardous task combination directing the patient to take themedications Tysabri and Remicade. The system (100) has flagged thecombination of these medication for review by a user i.e., an authorizednurse or physician. However, the flag can be later removed by the user(and the tasks merged within the unified care plan) after the hazard hasbeen reviewed.

As one skilled in the art may appreciate, the embodiments discussedherein are not limited and may be combined or otherwise customized foreach user or patient. According to the present disclosure the modulesdescribed herein may also comprise additional processes or instructionsthat may be executed in order to perform certain tasks described within.

The foregoing description of preferred and other embodiments is notintended to limit or restrict the scope or applicability of theinventive concepts conceived of by the Applicants. It will beappreciated with the benefit of the present disclosure that featuresdescribed above in accordance with any embodiment or aspect of thedisclosed subject matter can be utilized, either alone or incombination, with any other described feature, in any other embodimentor aspect of the disclosed subject matter.

In exchange for disclosing the inventive concepts contained herein, theApplicants desire all patent rights afforded by the appended claims.Therefore, it is intended that the appended claims include allmodifications and alterations to the full extent that they come withinthe scope of the following claims or the equivalents thereof.

What is claimed is:
 1. A method for normalizing care plans, comprising:digitizing, two or more care plans, if the two or more care plans aredetermined not to be in a common digital format; unifying, afterdigitizing the two or more care plans, the two or more care plans into aunified care plan; and communicating, the unified care plan.
 2. Themethod of claim 1, wherein digitizing two or more care plans comprises:converting, the two or more care plans into a common digital format;identifying, one or more tasks in each of the two or more care plans;and classifying, if at least one of the one or more tasks arestandardized, the at least one tasks.
 3. The method of claim 2, whereinif at least one of the one or more tasks are determined not to bestandardized, the method comprises one or more of: formatting, the atleast one tasks; receiving, input associated with the at least onetasks; and associating, content with the at least one task.
 4. Themethod of claim 2, wherein classifying the at least one tasks comprisesassociating one or more tags with the at least one tasks.
 5. The methodof claim 1, wherein communicating the unified care plan comprises one ormore of: selecting, one or more communication mediums for communicatingthe unified care plan; and communicating, the unified care plan usingone or more selected communication mediums.
 6. The method of claim 1,wherein unifying the two or more care plans into a unified care plancomprises: identifying, two or more care plans to be merged;consolidating, duplicate tasks to create at least one first referencetask; consolidating, similar tasks to create at least one secondreference task; establishing data links between the reference tasks,duplicate tasks, and similar tasks; and flagging, potentially harmfulconflicts; otherwise merging, if potential conflicts do not exist, thecare plan tasks and reference tasks into a unified care plan.
 7. Themethod of claim 5, wherein selecting one or more communication mediumscomprises selecting one or more of email, text messaging, web portal,and interactive video.
 8. The method of claim 1, further comprisingpersonalizing the unified care plan, wherein personalizing includesmodifying one or more of the contents, color, font, contrast, sound,orientation, metadata, or style associated with the unified care plan.9. The method of claim 1, wherein one or more of the unified care plancontent and personalization preferences may be accessed and modifiedthrough a GUI interface.
 10. The method of claim 3, wherein formattingthe at least one tasks comprises one or more of formatting quantitativeexpressions and language content using location data.
 11. Anon-transitory programmable storage device storing instructions thatwhen executed by one or more processors cause the one or more processorsto: digitize, two or more care plans, if the two or more care plans aredetermined not to be in a common digital format; unify, after digitizingthe two or more care plans, the care plans into a unified care plan; andcommunicate, the unified care plan.
 12. The non-transitory programmablestorage device of claim 11, wherein the instructions that cause the oneor more processors to normalize the two or more care plans compriseinstructions to cause the one or more processors to: convert, the two ormore care plans into a common digital format; identify, one or moretasks in each of the one or more care plans; and classify, if at leastone of the one or more tasks are standardized, the at least one tasks.13. The non-transitory programmable storage device of claim 12, whereinif the instructions cause the one or more processors to determine atleast one of the one or more tasks are not standardized, theinstructions comprise instructions to cause the one or more processorsto: format, the at least one tasks; receive, input associated with theat least one tasks; and associate, content with the at least one task.14. The non-transitory programmable storage device of claim 12, whereinthe instructions that cause the one or more processors to classify theat least one tasks comprise instructions to cause the one or moreprocessors to associate one or more tags with the at least one tasks.15. The non-transitory programmable storage device of claim 11, whereinthe instructions that cause the one or more processors to communicatethe unified care plan cause the one or more processors to one or moreof: select, one or more communication mediums for communicating theunified care plan; and communicate, the unified care plan using one ormore selected communication mediums.
 16. The non-transitory programmablestorage device of claim 11, wherein the instructions that cause the oneor more processors to unify the care plans into a unified care plancomprise instructions to cause the one or more processors to: identify,two or more care plans to be merged; consolidate, duplicate tasks tocreate at least one first reference task; consolidate, similar tasks tocreate at least one second reference task; establish data links betweenthe reference tasks, duplicate tasks, and similar tasks; and flagpotentially harmful conflicts; otherwise merge, if potential conflictsdo not exist, the care plan tasks and reference tasks into a unifiedcare plan.
 17. The non-transitory programmable storage device of claim15, wherein the instructions that cause the one or more processors toselect one or more communication mediums comprise instructions to causethe one or more processors to select one or more of email, textmessaging, web portal, and interactive video.
 18. The non-transitoryprogrammable storage device of claim 11, further comprising instructionsto cause the one or more processors to personalize the unified careplan, wherein the instructions to cause the one or more processors topersonalize include instructions to cause the one or more processors tomodify one or more of the contents, color, font, contrast, sound,orientation, metadata, or style associated with the unified care plan.19. The non-transitory programmable storage device of claim 11, whereinone or more of the unified care plan content and personalizationpreferences may be accessed and modified through a GUI interface. 20.The non-transitory programmable storage device of claim 13, wherein theinstructions that cause the one or more processors to format the atleast one tasks comprise instructions to cause the one or moreprocessors to format one or more of quantitative expressions andlanguage content using location data.